|
RDOS (''Real-time Disk Operating System'') was a real-time operating system released in 1972〔(OS History - Data General ) 〕 for the popular Data General Nova and Eclipse minicomputers. RDOS was capable of multitasking, with the ability to run up to 32 what were called "tasks" (similar to the current term threads) simultaneously on each of two grounds (foreground and background) within a 64 KB memory space. Later versions of RDOS were compatible with Data General's 16-bit Eclipse minicomputer line. A cut-down version of RDOS, without real-time background and foreground capability but still capable of running multiple threads and multi-user Data General Business Basic, was called Data General Diskette Operating System (DG-DOS or, now somewhat confusingly, simply DOS); another related operating system was RTOS, a Real-Time Operating System for diskless environments. RDOS on microNOVA-based "Micro Products" micro-minicomputers was sometimes called DG/RDOS. RDOS was superseded in the early 1980s by Data General's AOS family of operating systems, including AOS/VS and MP/AOS (MP/OS on smaller systems). ==Processing Model== RDOS was not designed to be a multi-user operating system or to support multiple applications running at one time. However, it did contain some provisions for multiprocessing. When the kernel booted up, it began by invoking a chosen application; by default, this was the Command Line Interpreter (CLI), although the system could be configured to start up a different application at boot time. (The separation of the user interface CLI from the operating system kernel, although typical of modern operating systems, was unusual at the time.) The CLI or other boot-time application constituted the top of a "stack" of application programs. Using the CLI, the user could invoke another application or utility. When this was done, the CLI was swapped out of memory and replaced by the invoked application, which then become level 1 on the stack. It was possible for an application to in turn swap itself out and invoke another application at level 2, and so on down to level 5. When an application exited, the next higher level application was "popped" off of the stack, loaded back into memory, and resumed at point where it left off. The memory available to application programs was divided by RDOS and RTOS into two partitions, referred to as "background" and "foreground". On DG computers lacking memory management hardware, RDOS booted up with nothing in the foreground, and all applications ran in the background by default. A program could be made to run in the foreground using the CLI EXFG command or the system .EXFG call; however, on an unmapped system, the program had to have been previously linked to load into memory at an address above the top of the application running in the background. Before launching a program in the foreground, RDOS checked the memory break address of the background program and the start address of the foreground program, and it would refuse to load the program in the foreground if there was an overlap. It was not uncommon to have several versions of an application program, all with identical code but linked so as to load into memory at different foreground starting addresses, in order to accommodate different combinations of background and foreground applications. Additionally, the foreground application had no direct access to the system console; in order to interact with a user, it had to access the device files for the console or another terminal. Systems with memory management did not have these programs. Each of the background and foreground partitions had its own system console, and both partitions started a CLI by default at boot time if so configured. RDOS arranged the memory mapping such that address space in both background and foreground started at address zero, so that it made no difference to a program if it ran in the background or foreground. RDOS allowed programs to run multiple threads, which were referred to as "tasks". Tasks shared all context except for their accumulators, which were saved and restored by RDOS for each task. RDOS provided simple memory locking calls for managing critical sections. Tasks ran in strict priority order; at each change of context (triggered by a task making a system call, or a device interrupt), RDOS selected the highest priority ready task, without exception, as befitting a real-time operating system. 抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』 ■ウィキペディアで「Data General RDOS」の詳細全文を読む スポンサード リンク
|